ipq40xx-generic: add linksys-mr8300 #2769

Djfe · 2023-01-24T00:36:37Z

Installation instructions:

Pay close attention:
The following change is required by all future firmwares. It only needs to be done once.
Installing OpenWRT 23+ (Kernel 5.15+) without it will brick your device!

Access http://192.168.1.1/fwupdate.html (user and password are admin)
Upload and install the factory image of OpenWrt 22.03.05.
After reboot connect to 192.168.1.1 via ssh and run fw_setenv kernsize 500000.
This allows U-Boot to boot Kernels upwards of 3MB successfully.
Check fw_printenv kernsize to verify the change. The number needs to start with 5 instead of 3.
Install the Gluon factory image of your community: sysupgrade -n -F <gluon-factory.bin>
Yes, sysupgrade is correct here: Pull Request. This device's sysupgrade supports flashing OpenWrt and Linksys factory images.

Full install instructions

Notes on this device:

They are raising compat version to warn users to modify the bootloader environment variable, so maybe let's only add this device in Gluon 2023 at the earliest to avoid a future failure of autoupdate? On the other hand there are communities with older gluon's that might want to have access to this device now while IPQ4019 is still considered good. (OT: IPQ807x was just added and new device support is flooding into OpenWrt)

The router has three WiFi radios. 5GHz channels are split like here: #1661 / #1666
My solution for now: remove kernelpackets for QCA9888-support until triple radio support is implemented. ~~We could flag the device as broken until then.~~ (done)
Freifunk doesn't require dfs channels anyways.
If there is a way to disable outdoor support (aka remove the config entry), then pls tell me where :)

The same thing could be done to add the Fritz!Repeater 3000, so it could atleast be deployed by Freifunk Communities.
Other devices that use the same packages-string: openmesh-a62 and plasma-cloud-pa2200. Does this also fix their 5GHz support? Looking at their dts files, they are triple radio devices as well, but I don't want to break anything accidentally.

How do I remove "dallas" from the expected image name? It might say dallas in the code but that name is not found in OpenWrt's firmware selector and it's also not in the image file (I looked at strings at start and end of the image file).
I found this but there is no exceptions for singular devices in there only for broadcom devices as a whole.

Not sure whether this is important:
When I enter config mode all LEDs are supposed to flash once. All of them are except the power led which stays lit throughout the whole reboot. The power led is on top of the router, every other led is on the back.
Also: there is no WiFi led.

AiyionPrime · 2023-01-24T16:19:36Z

The 3MB issue will require every user of this device to increase the partition in u-boot once in the device lifetime for updates beyond OpenWrt 22.03, right?

If so, that should be noted a instruction in the PR.

Not supporting all three radios qualifies for broken, not supported.

I'd favor getting three/n-interface support in gluon done before merging more of these devices, in order not to have to revisit these devices later on, as our time is currently fairly limited. But others might differ.

I'll do a full review once we settled on a scope for this device. And leave the following as a starting bit.

targets/ipq40xx-generic

Djfe · 2023-01-26T05:37:05Z

I addressed your notes.
I get what you mean: where do you draw the line with devices that are broken in this way? I'm ready to pledge for taking the responsibility on revisiting this device once n-interface support is added. I'm also ready to help in testing said support while it's still in development. Sure my device wouldn't need to be added, yet, for me to test the support. But I don't see much harm in adding it as broken.

That reminds me: I flagged the other two devices as broken in this PR, since they probably are.
@ecsv do you still have access to an Open-Mesh A62 or a Plasma Cloud PA2200 to confirm that 5GHz is broken? (either channels 36-64 or channels 100+ are probably not accessible right now)
According to commit openwrt/openwrt@4871fd2 QCA9888 is used for channels 36-64, but that can't be right, is it?
For my device it's the other way around. Disabling QCA9888 support disables channels 100+ and iw phy2 info confirms this.
phy1 and phy2 are IPQ4019 on my device while QCA9888 is phy0.
Hmm, on the other hand: wifi1 and wifi2 in the following dts are probably IPQ4019 since they are defined further in the soc's dtsi.
https://github.com/openwrt/openwrt/blob/4871fd2616acb03fefe69b068955dba36eb00770/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-pa2200.dts#L191-L209
So maybe they are used the other way around and my change (removing QCA9888 support) would break their channels 36-64.
(This won't be merged until we know for sure)
The Fritz!Repeater 3000 most definitely uses the QCA9888 for channels 100+ (same wifi setup as this device).
https://github.com/openwrt/openwrt/blob/db19efee951231b38573cffaadb15fad8f9c058d/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-fritzrepeater-3000.dts#L241

I'll do a full review once we settled on a scope for this device.

Sounds reasonable. I'll wait patiently for you and other maintainers to choose what to do next.
I'll switch this to draft state.

ecsv · 2023-01-26T08:05:30Z

That reminds me: I flagged the other two devices as broken in this PR, since they probably are.
@ecsv do you still have access to an Open-Mesh A62 or a Plasma Cloud PA2200 to confirm that 5GHz is broken? (either channels 36-64 or channels 100+ are probably not accessible right now)

I have a problem with the definition of "broken". Yes, the third radio (phy2 aka 5GHz IPQ40xx internal radio, aka channel 100+), but we are still using the QCA9888 for indoor installation with channel 36. We could even use that for 160 MHz (with half the NSS) - something which isn't supported with the internal 5GHz phy.

According to commit openwrt/openwrt@4871fd2 QCA9888 is used for channels 36-64, but that can't be right, is it?

Why can't this be right? It is how it is implemented in HW. You can also verify this in the DTS.

For my device it's the other way around. Disabling QCA9888 support disables channels 100+ and iw phy2 info confirms this.

Not sure what your device has to do with the A62/PA2200? It depends on the way the filters are added in front of the radio and what is inside the BDFs - not the actual PHY itself.

phy1 and phy2 are IPQ4019 on my device while QCA9888 is phy0.

Same here.

Djfe · 2023-01-26T15:37:53Z

Thanks for your quick reply and the explanations :)

Why can't this be right? It is how it is implemented in HW. You can also verify this in the DTS. [...] It depends on the way the filters are added in front of the radio and what is inside the BDFs - not the actual PHY itself.

You are right. I'm a novice and no hw expert by any means. My first impression while adding my router was that the wifi chip is only capable of certain frequencies. By now I know thanks to your reply that this is not the case. In other words: they had to split the frequency range in two (using filters) to allow wiring both chips to the same antennas. And depending on the board data files (calibration) the chip can act very differently. (If understood you correctly that is)

Same here.

Maybe because OpenWRT connects to pcie0 first. I read somewhere that radios are ordered in load order after boot up.
Do all three radios get MACs by Gluon? It could be that I'm mixing this up (so pls bear with me), but I remember only phy0 and phy1 but not phy2 having a mac in uci until I disabled QCA9888 due to this boot-order. I'm testing this now by enabling QCA9888 again.

EDIT:
I adjusted my commit and removed changes to the Open Mesh and the Plasma Cloud device. I'll leave it up to the Maintainers, whether they want to flag your device as broken. That part should be addressed in a different issue/PR if at all.

Djfe · 2023-01-28T21:59:23Z

sorry, for the spam, I just deleted my last post. I got confused by wikidevi listing my device as 256mb ram while it has 512mb.

Djfe · 2023-02-06T22:17:07Z

This might also depends on openwrt/openwrt#11693

targets/ipq40xx-generic

Djfe · 2023-02-24T03:07:59Z

This could be set back to "waiting-on-review" again to avoid confusion
Or to "blocked" instead if you still want tri-band support to be implemented first (fine by me)

AiyionPrime · 2023-02-24T10:47:41Z

Your PR is still in draft state. I can mark it as 'waiting-for-review', but that won't be true until you click the button "ready-for-review".

It was only labeled as such, as we had worked through a bunch of PRs a few days ago and I wanted others to have a look at yours as well.

docs/user/supported_devices.rst

Djfe · 2023-02-24T11:46:47Z

I thought this status would mean you were waiting for input from me and since NeoRaider already resolved his question I wasn't sure what we were waiting for, that's all ^^
2. status: waiting-on-author

I kept this as a draft since I didn't expect this device to be added before tri-band radio support.
As requested I removed the device from the supported list and updated the status to Ready for review :)

AiyionPrime

Maybe @ecsv can review this; I'd be fine with it, if its actions run through.

targets/ipq40xx-generic

Djfe · 2023-04-19T21:34:38Z

Thx, I addressed your requests

Edit:
Relevant for first installation:
2022.03.04 appears to be bootlooping on this device (ubi issues). This is resolved in 22.03-snapshot and Gluon master.
Use OpenWrt 2022.03.03 explicitly for the first install :)

AiyionPrime · 2023-05-21T11:42:36Z

rebase is necessary

Djfe · 2023-05-21T14:29:33Z

Done, I also updated the commit date.
I have a question:
Packages is applied on top of "defaults", right?
So the switch from ath10k-ct to ath10k also works for my device even though I adjusted packages, right?
(I don't have the time to rebuild and check opkg list currently)

AiyionPrime

Codewise this looks fine.
Testing the checklist (after your latest changes) on hardware is mandatory though.

Let me know when you found the time to test it and we can merge this.

rotanid · 2023-09-17T14:45:21Z

@Djfe do you still plan to test this device (after a rebase to the current master branch!) ?

Djfe · 2023-09-26T05:26:23Z

I redid all tests and updated the installation instructions in the PR description above.
Here is the new checklist. I require help in fixing MACs. One DSA related commit is causing trouble. Everything else runs fine.

Must be flashable from vendor firmware
- Web interface:
  https://openwrt.org/toh/linksys/mr8300#installation_of_2102_or_2203_from_oem_gui
- TFTP
- Other:
Must support upgrade mechanism
- Must have working sysupgrade
  - Must keep/forget configuration (sysupgrade [-n], firstboot)
- Gluon profile name matches autoupdater image name
  (lua -e 'print(require("platform_info").get_image_name())')
  linksys-mr8300-dallas
Reset/WPS/... button must return device into config mode
Primary MAC address should match address on device label (or packaging)
(https://gluon.readthedocs.io/en/latest/dev/hardware.html#hardware-support-in-packages)
```
e8:9f:80:ad:36:c1 label MAC (not used by any interface)

ea:9f:80:ad:36:c1 eth0
e8:9f:80:ad:36:c2 lan1 = primary mac
ea:9f:80:ad:36:c3 wifi2.4
ea:9f:80:ad:36:c4 wifi5 36-64
ea:9f:80:ad:36:c5 wifi5 100+

issues: lan2-4 and wan (some virtual mac addresses)
```
- When re-adding a device that was supported by an earlier version of Gluon, a
  factory reset must be performed before checking the primary MAC address, as
  the setting from the old version is not reset otherwise.
Wired network
- should support all network ports on the device
- must have correct port assignment (WAN/LAN)
  - ~~if there are multiple ports but no WAN port:~~
    - ~~the PoE input should be WAN, all other ports LAN~~
    - ~~otherwise the first port should be declared as WAN, all other ports LAN~~
Wireless network (if applicable)
- Association with AP must be possible on all radios
- Association with 802.11s mesh must work on all radios
- AP+mesh mode must work in parallel on all radios
LED mapping
- Power/system LED
  - Lit while the device is on
  - Should display config mode blink sequence
    (https://gluon.readthedocs.io/en/latest/features/configmode.html)
- ~~Radio LEDs~~
  - ~~Should map to their respective radio~~
  - ~~Should show activity~~
- Switch port LEDs
  - Should map to their respective port (or switch, if only one led present)
  - Should show link state and activity
Outdoor devices only:
- ~~Added board name to is_outdoor_device function in package/gluon-core/luasrc/usr/lib/lua/gluon/platform.lua~~
Cellular devices only:
- ~~Added board name to is_cellular_device function in package/gluon-core/luasrc/usr/lib/lua/gluon/platform.lua~~
- ~~Added board name with modem setup function setup_ncm_qmi to package/gluon-core/luasrc/lib/gluon/upgrade/250-cellular~~
Docs:
- Added Device to docs/user/supported_devices.rst No, it's broken.

Djfe · 2023-09-26T05:58:57Z

Before reading this, take a look at the MACs in the post below :)

MAC e8:9f:80:ad:36:c1 (label MAC) is missing entirely in Gluon. (it's either c2, c3 or c4)
For OpenWrt 22.03 it was necessary to set primary MAC to LAN interface MAC, I'm not sure whether this could be causing an issue now.
Regardless: c2 is detected as primary MAC now instead of c1, while WAN and LAN 2, 3 and 4 have no MAC based on the label mac at all (just some virtual MAC).

Issues are caused by the following lines (see openwrt/openwrt@550253b):

Since DSA support there is only eth0. eth1 doesn't exist anymore.
For some reason the commit sets eth0 to the label MAC (including LA bit). I'm not sure why it's necessary to set eth0 (as WAN is part of it)
WAN is never set anywhere in the script but gets the same label MAC but without the LA bit being set: e8:9f:80:ad:36:c1
I'm not sure whether setting MACs via ip link set dev translates correctly to Gluon as interfaces in Gluon have very different IPs now. Back in OpenWrt 22.03 setting them via ip link set dev eth0/eth1 worked though.

In OpenWrt 23.05 the ethernet MACs look correct, while in Gluon they don't. Maybe OpenWrt has additional code to fill in the other LANs/WAN interfaces?

For WiFi PHYs I'm wondering, why the LA bit is set by default in OpenWrt 23.05 (ea instead of e8):
ea:9f:80:ad:36:c5
(c5 is just the third radio (phy0), which Gluon currently can't make use of)

OpenWrt 22.03 had the most correct MACs. Here only the third wifi radio (wlan0) used the LA bit, but that might be correct in this case.

See for yourself:

MAC addresses in 23.05 rc3:

  root@OpenWrt:~# ip a
  1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
      inet 127.0.0.1/8 scope host lo
         valid_lft forever preferred_lft forever
      inet6 ::1/128 scope host 
         valid_lft forever preferred_lft forever
  2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
      link/ether ea:9f:80:ad:36:c1 brd ff:ff:ff:ff:ff:ff
      inet6 fe80::e89f:80ff:fead:36c1/64 scope link 
         valid_lft forever preferred_lft forever
  3: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
      link/ether e8:9f:80:ad:36:c2 brd ff:ff:ff:ff:ff:ff
  4: lan2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
      link/ether e8:9f:80:ad:36:c2 brd ff:ff:ff:ff:ff:ff
  5: lan3@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
      link/ether e8:9f:80:ad:36:c2 brd ff:ff:ff:ff:ff:ff
  6: lan4@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
      link/ether e8:9f:80:ad:36:c2 brd ff:ff:ff:ff:ff:ff
  7: wan@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN qlen 1000
      link/ether e8:9f:80:ad:36:c1 brd ff:ff:ff:ff:ff:ff
  11: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
      link/ether e8:9f:80:ad:36:c2 brd ff:ff:ff:ff:ff:ff
      inet 192.168.1.1/24 brd 192.168.1.255 scope global br-lan
         valid_lft forever preferred_lft forever
      inet6 fd4c:df3f:727f::1/60 scope global noprefixroute 
         valid_lft forever preferred_lft forever
      inet6 fe80::ea9f:80ff:fead:36c2/64 scope link 
         valid_lft forever preferred_lft forever
  12: phy1-ap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
      link/ether ea:9f:80:ad:36:c3 brd ff:ff:ff:ff:ff:ff
      inet6 fe80::e89f:80ff:fead:36c3/64 scope link 
         valid_lft forever preferred_lft forever
  13: phy2-ap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
      link/ether ea:9f:80:ad:36:c4 brd ff:ff:ff:ff:ff:ff
      inet6 fe80::e89f:80ff:fead:36c4/64 scope link 
         valid_lft forever preferred_lft forever
  14: phy0-ap0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN qlen 1000
      link/ether ea:9f:80:ad:36:c5 brd ff:ff:ff:ff:ff:ff

MAC addresses in Gluon master:

  root@ffac-mr8300:~# ip a
  1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
      inet 127.0.0.1/8 scope host lo
         valid_lft forever preferred_lft forever
      inet6 ::1/128 scope host 
         valid_lft forever preferred_lft forever
  2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
      link/ether ea:9f:80:ad:36:c1 brd ff:ff:ff:ff:ff:ff permaddr 00:03:7f:ba:db:ad
      inet6 fe80::e89f:80ff:fead:36c1/64 scope link 
         valid_lft forever preferred_lft forever
  3: lan1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-client state UP group default qlen 1000
      link/ether e8:9f:80:ad:36:c2 brd ff:ff:ff:ff:ff:ff permaddr 00:03:7f:ba:db:ad
  4: lan2@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-client state LOWERLAYERDOWN group default qlen 1000
      link/ether 00:03:7f:ba:db:ad brd ff:ff:ff:ff:ff:ff
  5: lan3@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-client state LOWERLAYERDOWN group default qlen 1000
      link/ether 00:03:7f:ba:db:ad brd ff:ff:ff:ff:ff:ff
  6: lan4@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-client state LOWERLAYERDOWN group default qlen 1000
      link/ether 00:03:7f:ba:db:ad brd ff:ff:ff:ff:ff:ff
  7: wan@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-wan state LOWERLAYERDOWN group default qlen 1000
      link/ether 00:03:7f:ba:db:ad brd ff:ff:ff:ff:ff:ff
  8: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
      link/ether 62:4b:c3:2f:25:88 brd ff:ff:ff:ff:ff:ff
  9: teql0: <NOARP> mtu 1500 qdisc noop state DOWN group default qlen 100
      link/void 
  12: br-client: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
      link/ether e8:9f:80:ad:36:c2 brd ff:ff:ff:ff:ff:ff
      inet6 2a03:2260:3006:114:ea9f:80ff:fead:36c2/64 scope global dynamic noprefixroute 
         valid_lft 599sec preferred_lft 29sec
      inet6 2a03:2260:3006:214:ea9f:80ff:fead:36c2/64 scope global dynamic noprefixroute 
         valid_lft 577sec preferred_lft 7sec
      inet6 fdac::ea9f:80ff:fead:36c2/64 scope global dynamic noprefixroute 
         valid_lft 86323sec preferred_lft 14323sec
      inet6 fe80::ea9f:80ff:fead:36c2/64 scope link 
         valid_lft forever preferred_lft forever
  13: br-wan: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
      link/ether 1a:40:46:d0:0d:00 brd ff:ff:ff:ff:ff:ff
  14: local-port@local-node: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-client state UP group default qlen 1000
      link/ether e8:9f:80:ad:36:c2 brd ff:ff:ff:ff:ff:ff
  15: local-node@local-port: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
      link/ether ac:41:95:40:f7:dc brd ff:ff:ff:ff:ff:ff
      inet6 fdac::ac/128 scope global deprecated 
         valid_lft forever preferred_lft 0sec
      inet6 fe80::ae41:95ff:fe40:f7dc/64 scope link 
         valid_lft forever preferred_lft forever
  16: wg_mesh: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
      link/none 
      inet6 fe80::2c8:44ff:fe1d:7904/128 scope link 
         valid_lft forever preferred_lft forever
  17: bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-client state UNKNOWN group default qlen 1000
      link/ether e8:9f:80:ad:36:c2 brd ff:ff:ff:ff:ff:ff
      inet6 fe80::ea9f:80ff:fead:36c2/64 scope link 
         valid_lft forever preferred_lft forever
  18: primary0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1532 qdisc noqueue master bat0 state UNKNOWN group default qlen 1000
      link/ether 1a:40:46:d0:0d:03 brd ff:ff:ff:ff:ff:ff
      inet6 fe80::1840:46ff:fed0:d03/64 scope link 
         valid_lft forever preferred_lft forever
  19: mesh-vpn: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1350 qdisc noqueue master bat0 state UNKNOWN group default qlen 1000
      link/ether de:2d:eb:3e:ce:7c brd ff:ff:ff:ff:ff:ff
      inet6 fe80::dc2d:ebff:fe3e:ce7c/64 scope link 
         valid_lft forever preferred_lft forever
  20: mesh0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1532 qdisc noqueue master bat0 state UP group default qlen 1000
      link/ether 1a:40:46:d0:0d:01 brd ff:ff:ff:ff:ff:ff permaddr ea:9f:80:ad:36:c3
      inet6 fe80::1840:46ff:fed0:d01/64 scope link 
         valid_lft forever preferred_lft forever
  21: mesh1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1532 qdisc noqueue master bat0 state UP group default qlen 1000
      link/ether 1a:40:46:d0:0d:05 brd ff:ff:ff:ff:ff:ff permaddr ea:9f:80:ad:36:c4
      inet6 fe80::1840:46ff:fed0:d05/64 scope link 
         valid_lft forever preferred_lft forever
  22: client0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-client state UP group default qlen 1000
      link/ether 1a:40:46:d0:0d:00 brd ff:ff:ff:ff:ff:ff permaddr ea:9f:80:ad:36:c3
      inet6 fe80::1840:46ff:fed0:d00/64 scope link 
         valid_lft forever preferred_lft forever
  23: client1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-client state UP group default qlen 1000
      link/ether 1a:40:46:d0:0d:04 brd ff:ff:ff:ff:ff:ff permaddr ea:9f:80:ad:36:c4
      inet6 fe80::1840:46ff:fed0:d04/64 scope link 
         valid_lft forever preferred_lft forever

And for comparison how MACs looked in OpenWrt 22.03:

  root@OpenWrt:~# ip a
  1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
      inet 127.0.0.1/8 scope host lo
         valid_lft forever preferred_lft forever
      inet6 ::1/128 scope host 
         valid_lft forever preferred_lft forever
  2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP qlen 1000
      link/ether e8:9f:80:ad:36:c1 brd ff:ff:ff:ff:ff:ff
  3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
      link/ether e8:9f:80:ad:36:c2 brd ff:ff:ff:ff:ff:ff
      inet6 fe80::ea9f:80ff:fead:36c2/64 scope link 
         valid_lft forever preferred_lft forever
  7: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
      link/ether e8:9f:80:ad:36:c1 brd ff:ff:ff:ff:ff:ff
      inet 192.168.1.1/24 brd 192.168.1.255 scope global br-lan
         valid_lft forever preferred_lft forever
      inet6 fd41:e11f:5c20::1/60 scope global noprefixroute 
         valid_lft forever preferred_lft forever
      inet6 fe80::ea9f:80ff:fead:36c1/64 scope link 
         valid_lft forever preferred_lft forever
  8: wlan2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
      link/ether e8:9f:80:ad:36:c4 brd ff:ff:ff:ff:ff:ff
      inet6 fe80::ea9f:80ff:fead:36c4/64 scope link 
         valid_lft forever preferred_lft forever
  9: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
      link/ether e8:9f:80:ad:36:c3 brd ff:ff:ff:ff:ff:ff
      inet6 fe80::ea9f:80ff:fead:36c3/64 scope link 
         valid_lft forever preferred_lft forever
  10: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
      link/ether ea:9f:80:ad:36:c5 brd ff:ff:ff:ff:ff:ff
      inet6 fe80::e89f:80ff:fead:36c5/64 scope link tentative 
         valid_lft forever preferred_lft forever

Djfe · 2023-09-26T06:21:23Z

Where I am (Gluon master):

ea:9f:80:ad:36:c1 eth0
e8:9f:80:ad:36:c2 lan1 = primary mac
00:03:7f:ba:db:ad wan, lan2,3,4
ea:9f:80:ad:36:c3 wifi2.4
ea:9f:80:ad:36:c4 wifi5 36-64
(ea:9f:80:ad:36:c5 wifi5 100+)

What I want to achieve (Gluon with MACs like OpenWrt 22.03):

ea:9f:80:ad:36:cx eth0 (I have no clue which number this needs since DSA, so "cx")
e8:9f:80:ad:36:c1 lan1,2,3,4 (label mac)
e8:9f:80:ad:36:c2 wan
e8:9f:80:ad:36:c3 wifi2.4
e8:9f:80:ad:36:c4 wifi5 36-64
(ea:9f:80:ad:36:c5 wifi5 100+)

neocturne · 2023-09-26T20:12:11Z

@Djfe Please attach the /etc/config/network generated by plain OpenWrt 23.05.

Djfe · 2023-09-28T20:17:12Z

root@OpenWrt:~# cat /etc/config/network 

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd38:1d79:7103::/48'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'

config device
	option name 'lan1'
	option macaddr 'e8:9f:80:ad:36:c2'

config device
	option name 'lan2'
	option macaddr 'e8:9f:80:ad:36:c2'

config device
	option name 'lan3'
	option macaddr 'e8:9f:80:ad:36:c2'

config device
	option name 'lan4'
	option macaddr 'e8:9f:80:ad:36:c2'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config device
	option name 'wan'
	option macaddr 'e8:9f:80:ad:36:c1'

config interface 'wan'
	option device 'wan'
	option proto 'dhcp'

config interface 'wan6'
	option device 'wan'
	option proto 'dhcpv6'

neocturne · 2023-10-02T13:57:08Z

Gluon currently deletes all device sections: https://github.com/freifunk-gluon/gluon/blob/master/package/gluon-core/luasrc/lib/gluon/upgrade/020-interfaces#L95

It might be enough to limit that to devices with a type option (or even just type "bridge"), but I'd like to have a closer look to make sure that we don't accidentally break anything. @blocktrron Do you remember why we started deleting such sections in 5ec8676?

Djfe · 2023-10-25T00:32:57Z

Please update the labels.
This PR is not waiting-on-author and doesn't need any testing at the moment.

maurerle · 2024-01-09T22:16:12Z

This is still waiting for tri-band support as specified in #1661 just like the device in #3057

github-actions bot added 3. topic: docs Topic: Documentation 3. topic: hardware Topic: Hardware Support 3. topic: package Topic: Gluon Packages labels Jan 24, 2023

AiyionPrime requested changes Jan 24, 2023

View reviewed changes

targets/ipq40xx-generic Outdated Show resolved Hide resolved

Djfe force-pushed the MR8300 branch from 6100ff5 to 28f06e3 Compare January 26, 2023 04:33

Djfe marked this pull request as draft January 26, 2023 05:37

AiyionPrime requested a review from blocktrron January 26, 2023 06:07

Djfe force-pushed the MR8300 branch from 28f06e3 to aef64de Compare January 26, 2023 15:21

AiyionPrime added the 2. status: waiting-on-review Awaiting review from the assignee but also interested parties. label Feb 21, 2023

neocturne reviewed Feb 22, 2023

View reviewed changes

targets/ipq40xx-generic Outdated Show resolved Hide resolved

AiyionPrime added 2. status: waiting-on-author Waiting on some action from the author and removed 2. status: waiting-on-review Awaiting review from the assignee but also interested parties. labels Feb 22, 2023

AiyionPrime requested changes Feb 24, 2023

View reviewed changes

docs/user/supported_devices.rst Outdated Show resolved Hide resolved

Djfe force-pushed the MR8300 branch from aef64de to 94ab29c Compare February 24, 2023 11:46

github-actions bot removed the 3. topic: docs Topic: Documentation label Feb 24, 2023

Djfe marked this pull request as ready for review February 24, 2023 11:46

AiyionPrime approved these changes Feb 24, 2023

View reviewed changes

AiyionPrime added 2. status: waiting-on-review Awaiting review from the assignee but also interested parties. and removed 2. status: waiting-on-author Waiting on some action from the author labels Feb 24, 2023

blocktrron reviewed Apr 19, 2023

View reviewed changes

targets/ipq40xx-generic Outdated Show resolved Hide resolved

blocktrron reviewed Apr 19, 2023

View reviewed changes

targets/ipq40xx-generic Outdated Show resolved Hide resolved

AiyionPrime added the 2. status: waiting-on-author Waiting on some action from the author label Apr 19, 2023

Djfe force-pushed the MR8300 branch from 94ab29c to 8e93fe8 Compare April 19, 2023 21:34

AiyionPrime added 2. status: waiting-on-review Awaiting review from the assignee but also interested parties. and removed 2. status: waiting-on-author Waiting on some action from the author labels Apr 29, 2023

Djfe force-pushed the MR8300 branch from 8e93fe8 to 1fe4180 Compare April 30, 2023 18:55

AiyionPrime added needs work 2. status: waiting-on-author Waiting on some action from the author and removed 2. status: waiting-on-review Awaiting review from the assignee but also interested parties. labels May 21, 2023

Djfe force-pushed the MR8300 branch from 1fe4180 to 7673556 Compare May 21, 2023 14:26

AiyionPrime approved these changes May 25, 2023

View reviewed changes

AiyionPrime added 0. type: question 5. needs: testing Testing of the changes is necessary and removed needs work labels May 25, 2023

ipq40xx-generic: add linksys-mr8300

7931f7a

Djfe force-pushed the MR8300 branch from 7673556 to 7931f7a Compare September 25, 2023 22:16

AiyionPrime removed 5. needs: testing Testing of the changes is necessary 2. status: waiting-on-author Waiting on some action from the author labels Oct 25, 2023

rotanid added the 2. status: blocked Marked as blocked because it's waiting on something label Jul 28, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ipq40xx-generic: add linksys-mr8300 #2769

ipq40xx-generic: add linksys-mr8300 #2769

Djfe commented Jan 24, 2023 •

edited

Loading

AiyionPrime commented Jan 24, 2023

Djfe commented Jan 26, 2023 •

edited

Loading

ecsv commented Jan 26, 2023

Djfe commented Jan 26, 2023 •

edited

Loading

Djfe commented Jan 28, 2023

Djfe commented Feb 6, 2023 •

edited

Loading

Djfe commented Feb 24, 2023

AiyionPrime commented Feb 24, 2023

Djfe commented Feb 24, 2023 •

edited

Loading

AiyionPrime left a comment •

edited

Loading

Djfe commented Apr 19, 2023 •

edited

Loading

AiyionPrime commented May 21, 2023

Djfe commented May 21, 2023 •

edited

Loading

AiyionPrime left a comment •

edited

Loading

rotanid commented Sep 17, 2023

Djfe commented Sep 26, 2023 •

edited

Loading

Djfe commented Sep 26, 2023 •

edited

Loading

Djfe commented Sep 26, 2023

neocturne commented Sep 26, 2023

Djfe commented Sep 28, 2023

neocturne commented Oct 2, 2023 •

edited

Loading

Djfe commented Oct 25, 2023

maurerle commented Jan 9, 2024

ipq40xx-generic: add linksys-mr8300 #2769

Are you sure you want to change the base?

ipq40xx-generic: add linksys-mr8300 #2769

Conversation

Djfe commented Jan 24, 2023 • edited Loading

Installation instructions:

Notes on this device:

AiyionPrime commented Jan 24, 2023

Djfe commented Jan 26, 2023 • edited Loading

ecsv commented Jan 26, 2023

Djfe commented Jan 26, 2023 • edited Loading

Djfe commented Jan 28, 2023

Djfe commented Feb 6, 2023 • edited Loading

Djfe commented Feb 24, 2023

AiyionPrime commented Feb 24, 2023

Djfe commented Feb 24, 2023 • edited Loading

AiyionPrime left a comment • edited Loading

Choose a reason for hiding this comment

Djfe commented Apr 19, 2023 • edited Loading

AiyionPrime commented May 21, 2023

Djfe commented May 21, 2023 • edited Loading

AiyionPrime left a comment • edited Loading

Choose a reason for hiding this comment

rotanid commented Sep 17, 2023

Djfe commented Sep 26, 2023 • edited Loading

Djfe commented Sep 26, 2023 • edited Loading

Djfe commented Sep 26, 2023

neocturne commented Sep 26, 2023

Djfe commented Sep 28, 2023

neocturne commented Oct 2, 2023 • edited Loading

Djfe commented Oct 25, 2023

maurerle commented Jan 9, 2024

Djfe commented Jan 24, 2023 •

edited

Loading

Djfe commented Jan 26, 2023 •

edited

Loading

Djfe commented Jan 26, 2023 •

edited

Loading

Djfe commented Feb 6, 2023 •

edited

Loading

Djfe commented Feb 24, 2023 •

edited

Loading

AiyionPrime left a comment •

edited

Loading

Djfe commented Apr 19, 2023 •

edited

Loading

Djfe commented May 21, 2023 •

edited

Loading

AiyionPrime left a comment •

edited

Loading

Djfe commented Sep 26, 2023 •

edited

Loading

Djfe commented Sep 26, 2023 •

edited

Loading

neocturne commented Oct 2, 2023 •

edited

Loading